optimize settle_funds and accrue fee rebate at time of trade instead of event queue #149
Conversation
…ferrer_pc_wallet; Giving open_orders rebate at the time of trade instead of at time of event queue processing
There was a problem hiding this comment.
Will leave open to give @sconybeare a chance to take a look next week. But these changes all look good to me.
| if !maker { | ||
| let referrer_rebate = fees::referrer_rebate(native_fee_or_rebate); | ||
| open_orders.referrer_rebates_accrued += referrer_rebate; | ||
| } |
There was a problem hiding this comment.
I think that if this is deployed in a program upgrade, any rebates sitting in the event queues will be lost.
There was a problem hiding this comment.
Yes, you're right. So the total loss would be the 20% of the fee value of all trades that are on the event queue at the time this deployment goes out. My instinct is that it's a small loss because cranks usually clear out the event queue very quickly and most queues don't have trades on them, but I don't actually know the stats on this.
It simplifies the settling process for us by a lot. With the referrer rebate being granted at time of trade, we can put a SettleFunds instruction right after a NewOrder instruction and not have to wait to send a settle funds. We try to hide the settling thing as much as possible from users 😄
There was a problem hiding this comment.
My guesstimate is that both the UX improvement and the 20k compute units saved are worth more than the 20% of the fee value of all trades at time of the deployment.
There was a problem hiding this comment.
20k compute units 😮 ? Spl token transfer CPI usually is ~3k units.
But even 3k units saving is good.
It saves something like 20k compute on settle funds by avoiding the extra CPI call. This has been working well on devnet for a month.